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1  Introduction 

Timed  planning  is  to  schedule  a  set  of  given  timed  tasks  to  fulfill  certain  desired 
properties.  It  has  important  implications  in  a  variety  of  domains,  e.g.,  real-time 
operating  system,  military  planning,  etc.  In  a  broad  view,  Timed  Planning  is 
a  generalization  of  the  well-understood  schedulability  problem  of  a  given  set  of 
timed  tasks  [3]. 

In  order  to  handle  the  generalized  Timed  Planning  problem,  in  this  work 
we  model  a  timed  task  as  a  timed  process  specified  using  the  well-established 
timed  specification  language  Timed  CSP  [5].  A  task  may  have  complicated  timed 
behavior  patterns.  Timed  CSP  is  chosen  over  other  timed  formalisms  (like  Timed 
Automata  [2],  Task  Automata  [8],  etc.)  is  because  of  its  compositional  and  event- 
based  nature.  In  order  to  state  more  timing  behaviors  of  a  timed  task,  such  as 
deadline  and  period  of  a  task  and  time-related  constrains  among  events,  we 
extend  Timed  CSP  with  capabilities  to  state  timed-related  system  requirements 
in  a  modular  manner.  Namely,  each  process,  which  is  a  task  or  a  sub-task,  may 
be  associated  with  a  set  of  localized  timing  requirements.  The  Timed  Planning 
problem  is  then  reduced  to  a  feasibility  test  of  the  tasks.  Based  on  the  notion  of 
constraint  solving  [12, 13],  we  have  developed  a  fully  automated  reasoning  engine 
which  clarifies  whether  it  is  possible  that  a  given  set  of  tasks  are  scheduled  in 
a  way  to  fulfill  the  timed  requirements  and  generate  a  feasible  scheduling  (if 
possible).  Besides,  feasibility  checking,  as  well  as  various  property  verification 
can  be  applied  to  Timed  Planning  specifications.  Feasibility  checking  helps  users 
to  debug  the  conflicts  of  the  timing  constraints  specified  in  the  systems. 

We  study  a  real  military  attack,  the  Pearl  Harbor  Attack,  which  is  a  carefully 
planned  military  strike  conducted  by  the  Japanese  navy.  The  whole  mission 
consists  of  several  sub-missions,  each  has  its  own  duty  and  timing  constraints. 
We  model  the  main  attack  plan  conducted  on  December  7,  1941.  It  is  only  a  sub 
plan  of  the  whole  pearl  harbor  attack  plan  which  also  consists  of  preparation 
plans  and  follow-up  plans  after  the  main  attack. 

In  this  project,  we  apply  Timed  Planning  to  the  classic  scheduling  domain, 
job-shop  scheduling  problem  (both  deterministic  and  preemptive).  This  problem 
cannot  be  modeled  and  solved  using  pure  Timed  CSP  specifications.  We  also 
apply  our  approach  to  handle  the  extended  job-shop  scheduling  problems,  where 
jobs  can  have  more  complex  relations,  such  as  a  composition  of  operational 
behaviors  with  communications,  and  jobs  with  deadlines  and  relative  timing 


constraints,  which  no  other  current  work  are  able  to  support.  It  is  the  main 
feature  of  our  work  differs  from  [1]  which  proposed  a  mechanism  for  modeling  the 
job-shop  scheduling  problems  in  Timed  Automata  and  hence  finding  the  optimal 
solutions.  The  job-shop  scheduling  problem  can  be  very  naturally  modeled  in 
Timed  Planning  processes,  whose  executions  correspond  to  feasible  schedules. 
In  this  work,  the  job-shop  scheduling  problem  can  be  reduced  to  a  problem  of 
finding  a  complete  execution  (an  execution  that  terminates)  with  the  minimum 
execution  time. 

Another  application  is  Timed  Reminding  System,  which  is  a  reminding  sys¬ 
tem  design  to  generate  real  time  scheduler  for  coordinating  multiple  reminders 
and  remedying  possible  conflicts.  One  typical  application  is  to  design  a  remind¬ 
ing  system  for  the  dementias  to  help  them  doing  daily  activities  such  as  take 
medication  at  the  right  time,  remind  them  prepare  lunch,  turn  off  stove  after 
cooking  and  etc.  Our  timed  reminding  system  consists  of  multiple  reminders. 
Reminders  can  be  triggered  at  a  specific  time  or  by  some  events.  Reminders  can 
interrupt  with  each  other  due  to  the  unexpected  activities  of  the  participant. 
The  reminder  which  has  been  interrupted  also  can  resume  to  the  previous  one  if 
the  interrupted  one  is  ended  before  the  expiry  time. 

The  underlying  reasoning  mechanism  is  Constraint  Logic  Programming  (CLP) 
[13],  which  has  been  successfully  applied  to  model  programs  and  transition  sys¬ 
tems  for  the  purpose  of  verification  [10,15],  showing  that  their  approach  out¬ 
performs  the  well-known  state-of-art  systems.  In  our  previous  work  [6],  we  con¬ 
structed  a  reasoning  tool  using  CLP  as  an  underlying  reasoning  mechanism  for 
Timed  CSP  .  In  this  work,  we  extend  the  reasoning  mechanism  to  support  the 
Timed  Planning  specification.  Our  approach  starts  with  a  systematic  transla¬ 
tion  of  the  semantics  of  Timed  Planning  into  CLP.  The  operational  semantics  is 
encoded  to  CLP,  where  a  set  of  global  and  local  variables  need  to  be  captured 
during  the  execution,  then  a  set  of  safety  and  liveness  properties  be  verified.  We 
implement  a  prototype  reasoning  engine  based  on  one  of  the  established  CLP 
solvers,  CLP(7?.)  [14].  CLP(Al)  is  chosen  for  its  support  of  real  numbers  and  con¬ 
tinuous  time  variables.  A  number  of  theories,  libraries  and  shortcuts  have  been 
developed  for  easy  querying  and  proving. 

The  remainders  of  the  report  are  organized  as  follows.  Section  2  briefly  review 
the  background  of  the  work,  i.e. ,  the  Timed  CSP  specification  language  and  the 
Constraint  Logic  Programming  paradigm.  Section  3  discusses  the  syntax  and 
semantics  of  Timed  Planning,  while  Section  4  introduces  the  reasoning  method 
for  Timed  Planning.  Section  5  shows  how  we  model  the  Pearl  Harbor  Attack 
plans  in  Timed  planning  specification.  Section  6  presents  how  to  use  Timed 
Planning  to  solve  job-shop  scheduling  problems.  Section  8  concludes  this  report. 

2  Overview 

Timed  CSP  Language  Hoare’s  CSP  [11]  is  an  event  based  notation  primarily 
aimed  at  describing  the  sequencing  of  behavior  within  a  process  and  the  synchro¬ 
nization  of  behavior  (or  communication)  between  processes.  Timed  CSP  extends 


CSP  by  introducing  a  capability  to  quantify  temporal  aspects  of  sequencing  and 
synchronization.  Inherited  from  CSP,  Timed  CSP  adopts  a  symmetric  view  of 
process  and  environment.  Events  represent  a  cooperative  synchronization  be¬ 
tween  process  and  environment.  Both  process  and  environment  may  control  the 
behavior  of  the  other  by  enabling  or  refusing  certain  events  and  sequences  of 
events. 

Definition  1  (Timed  CSP).  A  Timed  CSP  process  is  defined  by  the  following 
syntax, 

P  ::=  Stop  |  Skip  |  Run  |  e  P  \  e  :  E  -»  P(e)  \  e@t  -*•  P{t) 

I  PiOP2\p1nP2\P1  X\\Y  P2\Pi\[X]\P2\Pi\\\P2 
I  Pi;  P2  |  Pi  V  P2  |  PI  >  P2  |  Wait  d  \  Pi  v{d}  P2 
I  liX.P(X) 

Run is  a  process  always  willing  to  engage  any  event  in  E.  Stop  denotes  a 
process  that  deadlocks  and  does  nothing.  A  process  that  terminates  is  written 
as  Skip.  A  process  which  may  participate  in  event  e  then  act  according  to  pro¬ 
cess  description  P  is  written  as  e@t  —>  P(t).  The  (optional)  timing  parameter  t 
records  the  time,  relative  to  the  start  of  the  process,  at  which  the  event  e  occurs 
and  allows  the  subsequent  behavior  P  to  depend  on  its  value.  The  process  e  P 
delays  process  P  by  t  time  units  after  engaging  event  e.  The  external  choice  op¬ 
erator,  written  as  P  □  Q,  allows  a  process  of  choice  of  behavior  according  to 
what  events  are  requested  by  its  environment.  Internal  choice  represents  vari¬ 
ation  in  behavior  determined  by  the  internal  state  of  the  process.  The  parallel 
composition  of  processes  P±  and  P2,  synchronized  on  common  events  of  their 
alphabets  X,  Y  (or  a  common  set  of  events  A)  is  written  as  P\  x  \  \y  P2  (or 
Pi  |[  A] |  P2).  The  sequential  composition  of  Pi  and  P2,  written  as  Pi;  P2,  acts 
as  Pi  until  Pi  terminates  by  communicating  a  distinguished  event  /  and  then 
proceeds  to  act  as  P2.  The  interrupt  process  Pi  V  P2  behaves  as  Pi  until  the  first 
occurrence  of  event  in  P2,  then  the  control  passes  to  P2.  The  timed  interrupt 
process  Pi  V{d}  P2  behaves  similarly  except  Pi  is  interrupted  as  soon  as  d  time 
units  have  elapsed.  A  process  which  allows  no  communications  for  period  d  time 
units  then  terminates  is  written  as  Wait  d.  The  timeout  construct  written  as 
Pi  >{d}  P2  passes  control  to  an  exception  handler  P2  if  no  event  has  occurred 
in  the  primary  process  Pi  by  some  deadline  d.  Recursion  is  used  to  give  finite 
representation  of  non-terminating  processes.  The  process  expression  /i  X  •  P{X) 
describes  processes  which  repeatedly  act  as  P(X). 

The  detailed  illustration  of  each  process  can  be  found  in  [18].  The  semantics 
of  a  Timed  CSP  process  is  precisely  defined  either  by  identifying  how  the  process 
may  evolve  through  time  or  by  engaging  in  events  (i.e.,  the  operational  semantics 
defined  in  [19])  or  by  stating  the  set  of  observations,  e.g.,  traces,  failures  and 
timed  failures  (i.e.,  the  denotational  semantics  as  defined  in  [4]).  In  this  work, 
Timed  CSP  is  used  to  specify  interactive  timed  tasks. 

CLP  Preliminaries  Constraint  Logic  Programming  (CLP  [13])  began  as  a 
natural  merger  of  two  declarative  paradigms:  constraint  solving  and  logic  pro- 


gramming.  This  combination  helps  make  CLP  programs  both  expressive  and 
flexible,  and  in  some  cases,  more  efficient  than  other  kinds  of  programs.  The 
CLP  scheme  defines  a  class  of  languages  based  upon  the  paradigm  of  rule-based 
constraint  programming,  where  CLP  (TV)  is  an  instance  of  this  class.  We  present 
some  preliminary  definitions  about  CLP. 

Definition  2  (Atom,  Rule  and  Goal).  An  atom  is  of  the  form  p(t),  where 
p  is  a  user  defined  predicate  symbol  and  t  is  a  sequence  of  terms  ‘t\,h-.,  tn  ’.  A 
rule  is  of  the  form  A  :  —B,P  where  the  atom  A  is  the  head  of  the  rule,  and  the 
sequence  of  atoms  B  and  the  constraint  constitute  the  body  of  the  rule.  A  goal 
has  exactly  the  same  format  as  the  body  of  the  rule  of  the  form  1  —  B,P .  If  B 
is  an  empty  sequence  of  atoms,  we  call  this  a  (constrained)  fact.  All  goals,  rules 
and  facts  are  terms. 

The  universe  of  discourse  V  of  our  CLP  program  is  a  set  of  terms,  integers, 
and  fists  of  integers.  A  constraint  is  written  using  a  language  of  functions  and 
relations.  They  are  used  in  two  ways,  in  the  basic  programming  language  to 
describe  expressions  and  conditions,  and  in  user  assertions,  defined  below.  In  this 
report,  we  will  not  define  the  constraint  language  explicitly,  but  invent  them  on 
demand  in  accordance  with  our  examples.  Thus  the  terms  of  our  CLP  programs 
include  the  function  symbols  of  the  constraint  language.  A  ground  instance  of 
a  constraint,  atom  and  rule  is  defined  in  obvious  way.  A  ground  instance  of  a 
constraint  is  obtained  by  instantiating  variables  therein  from  T>.  The  ground 
instances  of  a  goal  G,  written  [G]  is  the  set  of  ground  atoms  obtained  by  taking 
all  the  true  ground  instances  of  G  and  then  assembling  the  ground  atoms  therein 
into  a  set.  We  write  Gi  |=  G2  to  mean  that  for  all  groundings  6  of  Gi  and  G2, 
each  ground  atom  in  G\9  appears  in  G2(9. 

Let  G  =  (Si, ...,  Bn,  P)  and  P  denote  a  goal  and  program  respectively.  Let 
R  =  A  :  —Ci, ...,  Cm,  tffi  denote  a  rule  in  P,  written  so  as  none  of  its  variables 
appear  in  G.  Let  A  =  B,  where  A  and  B  are  atoms,  be  shorthand  for  equations 
between  their  corresponding  arguments.  A  reduct  of  G  using  R  is  of  the  form 

(Bi,  ■■■,  Sj_l7  Ci, ...,  Cm,  Bi+1, ...,  Bn,  Bi  =  A  A  A 

provided  Bi  =  A  A  A  ifi  is  satisfiable.  A  derivation  sequence  is  a  possibly 
infinite  sequence  of  goals  Go,  Gi, ...  where  Gi,  i  >  0  is  a  reduct  of  Gi_i.  If  there 
is  a  last  goal  Gn  with  no  atoms,  notationally  (□,<?)  and  called  a  terminal  goal, 
we  say  that  the  derivation  is  a  successful  and  that  the  answer  constraint  is  W 
A  derivation  is  ground  if  every  reduction  therein  is  ground. 

CLP  has  been  successful  as  a  programming  language,  and  more  recently,  as  a 
model  of  executable  specifications.  There  have  been  numerous  works  which  use 
CLP  to  model  system  modeling  or  programs  and  which  use  an  adaptation  of  the 
CLP  proof  system  for  proving  certain  properties  [16]  [6] .  In  this  work,  we  follow 
this  trends  and  use  existing  powerful  constraint  solvers  for  mechanized  Timed 
Planning. 


3  Timed  Planning  Specification 


In  our  setting,  Timed  CSP  is  used  to  specify  the  timed  tasks,  which  are  multi¬ 
threaded  and  interactive.  However,  Timed  CSP  lacks  expressiveness  for  stating 
system  requirements  which  constraints  all  behavioral  traces  of  a  given  process, 
i.e. ,  the  desired  properties  of  Timed  Planning.  Thus,  we  extend  Timed  CSP  with 
capability  of  stating  requirements  on  process  deadlines,  event  ordering,  etc. 

3.1  syntax 

In  a  Timed  Planning  specification,  a  process  is  extended  with  an  optional  Where 
clause,  which  consists  of  a  (first  order)  predicate  over  a  predefined  set  of  time 
variables.  For  instance,  given  a  process  P,  the  variable  P. Start  (P.End)  denotes 
the  exact  starting  (ending)  time  of  the  process  P.  More  specifically,  P. Start 
captures  the  starting  time  of  a  process  P  when  its  first  event  is  enabled  or  when 
the  “wait  d"  process  is  enabled  if  P  starts  with  a  WAIT  process.  P.End  is  the 
ending  time  of  the  process  P,  i.e.,  the  starting  time  of  process  Stop.  If  the  pro¬ 
cess  is  non-terminating,  then  P.End  =  oo.  Naturally,  P.End  >  P. Start  all  the 
time.  Using  the  two  variables,  a  deadline  property  (a  task  must  be  accomplished 
within  a  certain  time)  is  expresses  as  P  Where  P.End  —  P. Start  ^  d  where 
d  is  a  constant  (d  £  R+).  In  other  scenarios,  there  may  be  a  requirement  on 
some  event  to  occur  at  some  exact  time,  e.g.,  attending  a  meeting  at  10:00.  A 
time  variable  Engage  is  attached  to  an  event  e  to  denote  the  exact  time  when 
e  is  engaged,  in  the  form  of  e. Engage. 

Example  1.  Kate  needs  to  attend  a  meeting  which  starts  at  10:00  and  lasts  less 
than  two  hours.  She  will  go  home  after  the  meeting. 

Kate  =  arrive  — >  Meeting ;  gohome  — ►  Skip 

Where  arrive. Engage  ^  10  A  Meeting. Start  =  10  A 
Meeting. End  —  Meeting. Start  ^  2 

where  for  simplicity  we  write  10  to  represent  10:00.  □ 

In  addition,  we  use  the  variable  P.Tes,  where  Tes  stands  for  Timed  Event  Set, 
to  record  the  engage  time  of  all  events  engaged  so  far,  which  can  be  viewed  as 
a  history  of  the  execution.  We  can  retrieve  the  information  we  are  interested  in 
from  the  set  Tes.  The  following  example  illustrates  a  constraint  concerning  the 
number  of  occurrences  of  events  in  P. 

Example  2.  In  a  restaurant,  the  staff  in  the  kitchen  cook  and  supply  food  to  the 
counter,  the  staff  at  the  counter  takes  orders  and  delivers  food  to  the  customers. 

Kitchen  =  cook  —*  supply  — >  Kitchen 
Counter  =  order  — >  serve  — ►  Counter 

Where  serve. Engage  -  order. Engage  <  60 
Med  =  Kitchen  ||  Counter 

Where  Tes  [  supply  >  Tes  J.  serve  A  Tes  J.  supply  —  Tes  J,  serve  ^  10 
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P  Where  WherePred 
WherePre  A  WherePred 
WherePre  V  WherePred 
WherePre  •$=>  WherePred 
WherePre  =>  WherePred 
WherePre  \  true  \  false 
WhereExpr  ~  WhereExpr 
[Name]  Start 
[Name]  End 
[Name.  ]Tes 
Name.  Engage 
Name. Engage; 
WhereExpr  ©  WhereExpr 
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-  starting  time  of  a  process 
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-  timed  event  set  of  a  process 

-  time  of  the  occurrence  of  Name 

-  time  of  the  ith  occurrence  of  Name 

-0  €{+,-} 


Fig.  1.  Timed  Planning  Process  Syntax 


where  Tes  J,  supply  is  the  number  of  occurrences  of  event  supply  in  the  event 
set  Tes.  The  Where  clause  guarantees  for  each  order,  there  is  available  food 
to  be  delivered.  □ 

The  syntax  of  the  Timed  Planning  process  is  summarized  in  Figure  1  where 
Name  is  a  sequence  of  characters  starting  an  alphabet,  i.e.,  an  event  or  a  process. 
Note  that  if  Name  is  missing,  it  defaults  to  the  process  name  on  the  left  hand 
side.  To  differentiate  events  of  the  same  name  in  different  processes,  we  write 
P.a  to  denote  the  event  a  in  P  whenever  necessary.  By  using  the  syntax  defined 
above,  common  Timed  Planning  requirements  can  be  specified  easily. 

We  also  add  some  functions  over  Tes  to  capture  different  aspects  of  the 
execution  which  can  be  used  in  the  where  predicates. 

—  Tes  J.  a  :  the  number  of  occurrences  of  event  a  in  the  timed  event  set  Tes. 

—  first{ Tes):  The  first  event  appear  in  Tes. 

—  lastly  Tes):  The  last  event  appear  in  Tes. 

Example  3  (Common  requirements).  For  instance,  we  can  specify  the  deadline 
of  a  process,  order  of  events,  separation  time  between  events  and  etc,  which  are 
shown  in  Table  1.  □ 


3.2  Data  types 

The  Timed  Planning  specification  supports  some  primitive  data  types,  including 
integers,  real  numbers,  boolean  values  and  list.  We  can  define  global  variables 


Requirements 

TP  representation 

Process  P  must  be  finished  within  time  d 
Process  P  must  be  finished  before  time  d 

Max  separation  time  between  two  events  ei,  e2  is  d. 
ei  must  happen  before  ei 

P.End-  P.Start^  d 
P.End<  d 
e2. Engage-  ei. Engage^  d 
e2. Engage-  ci.Engage>  0 

Table  1.  Basic  Timed  Planning  Patterns 


or  process  parameters. 

R  :  RealNumber 

N  :  Integers 

B  :  BooleanType 

Seq  T  :  Sequence  of  elements  of  type  T 

SetT  :  Set  of  elements  of  type  T 


For  Seq  T  and  Set  T,  type  T  £  {R,  N,B}. 


3.3  Operational  Semantics  of  Timed  Planning 

An  operational  semantics  provides  a  way  of  interpreting  a  language  by  stepping 
through  executions  of  programs  written  in  that  language.  It  describes  an  opera¬ 
tional  understanding  of  the  language.  The  operational  semantics  of  Timed  CSP 
is  precisely  defined  in  Schneider  [19]  by  using  the  combination  of  two  relations: 
event  transition  and  evolution.  The  semantics  model  for  Timed  Planning  con¬ 
sists  of  three  components:  the  event  and  timed  transitions  which  are  inherited 
from  Timed  CSP,  a  Where  predicate  which  must  be  satisfied  by  this  model, 
and  an  Timed  stamped  set.  A  Timed  stamped  set  (Tss)  is  a  record  of  an  execu¬ 
tion,  consisting  of  a  set  of  process  related  time  stamps,  namely  the  starting  and 
ending  times  of  processes,  and  a  timed  event  set  (Tes)  which  is  a  set  of  timed 
events.  Tes  is  a  subset  of  Tss:  Tes  C  Tss.  A  timed  event  is  a  pair  drawn  from 
e  x  R+  where  e  £  £,  consisting  of  a  time  and  an  event  engage  time  value. 

We  define  the  state  of  a  process  as  a  quadruple  (P,  t ,  W,  Tss)  where  P  is  the 
process,  t  is  the  current  time,  W  is  the  Where  predicate  and  Tss  is  the  timed 
stamped  set  of  the  model.  Tss  keeps  value  for  all  variables.  At  each  transition, 
an  evaluation  of  the  system  requirement  W  is  performed.  If  the  current  state 
satisfies  the  requirement,  the  transition  can  be  enabled,  otherwise  not. 

Definition  3.  The  operational  semantics  of  a  Timed  Planning  specification  is 
a  timed  transition  where  the  state  is  a  quadruple  ( P ,  t,  W,  Tss),  and  event  tran¬ 
sitions  and  evolution  transitions  are  defined  by  the  rules: 

—  (P,  t,  W,  Tss)  A  (P',  t,  W,  Tss')  where  3  i  :  N  •  Tss  U  {(a. Engage,,  t)}  1= 
W 

—  (P,  t ,  W,  Tss)  (P\  t  +  d,  W,  Tss1)  where  d>0 


Tss  U  {(e. Engage*,  f)}  |=  W 


Pi^Pi 


[  e  £  X  U  {t}  \  Y,  Tes  j.  e  =  i  —  1 


{Pi  x\\y  P2,  f,  W,  Tss ) 

(P{  x\\y  Pi,  t,  W,  Tss  U  {(e. Engage;,  t)}) 


Tss  U  {(e.ENGAGE;,  t)}  \=  W  P2  -4  P2 

{P\  x\\y  P2,  t,  W,  Tss)  -A 

(-Pi  x  ||  y  P2,  t,  W,  Tss  U  {(e.ENGAGE;,  f)}} 


e  €  Y  U  {r}  \  X,  Tes  J.  e  =  i  —  1 


Tss  U  {(e.ENGAGE;,  t)}  \=  W  Pi  -4  P[  P2  A  P2 

_ — _ — _ [  e  e  X  n  Y,  Tes  {  e 

(Pi  x\\y  Pi,t ,  W,  Tss)  A 

(P'i  x\\y  P2,t,  W ,  TssU  {(e.ENGAGE;,  £)}) 

Tss  U  {(/.Engage,  t)}  \=  W  Pi  'L  p[  P2  'L  p' 

(Pi  x\\y  Pi,t,  W,  Tss)  A  (P[  X\\Y  P^t,  W,  Tss  U  {(End,  i)}) 

Pi  P[  P2  ^  Pi 

(Pi  x\\y  Pi,t,  W,  Tss)  4  (P(  x  ||  y  P2,t+d,  W,  Tss) 

Fig.  2.  Operational  Semantics  of  compositional  operator  Pi  x||y  P2 


where  P’  is  the  subsequent  process  of  P  by  involving  either  a  event  transition  (— >) 
or  a  timed  transition  (-w).  Tss'  is  a  timed  stamped  set  with  updated  Engage, 
Start,  and  End  variables.  □ 

The  represents  an  event  transition,  whereas  is  a  timed  transition.  3  i  : 
N  •  Tss  U  {(a. ENGAGE;,  t)}  1=  W  is  an  evaluation  of  the  current  state,  which 
is  used  to  check  whether  the  current  timed  stamped  set  Tss  fulfills  the  system 
requirements  W  or  not. 

In  the  operational  semantics,  we  define  both  event  transition  and  timed  tran¬ 
sition  relations  for  all  primary  and  compositional  operators  in  Timed  Planning 
specification,  which  are  fully  presented  in  [7].  The  operational  semantics  of  the 
alphabetized  parallel  composition  operator  Pi  x\\y  Pi  are  illustrated  in  Figure 
2.  The  first  two  rules  state  that  either  of  the  components  (P±  or  P2)  may  engage 
an  event  as  long  as  the  event  is  not  shared,  only  if  the  event  with  the  current 
time  satisfies  the  requirements.  The  next  rule  states  that  a  shared  event  can  be 
engaged  simultaneously  by  both  components  as  long  as  the  event  satisfies  the 
requirements.  The  fourth  rule  is  a  special  case  for  the  third  rule,  whereas  the 
event  is  the  /  which  is  a  special  event  used  purely  to  denote  termination.  A  new 
pair  (End,  t)  is  added  to  the  Tss  and  hence  checked.  The  last  rule  says  that  the 
composition  may  allow  time  elapsing  when  both  the  components  do  .  We  define 
the  semantics  rules  for  each  operators  in  Timed  CSP,  which  are  fully  illustrated 


Example  3  Take  a  printer  process  as  an  example.  After  the  printer  accepts  a 
job,  it  needs  to  print  this  job  within  30  to  60  seconds.  Assume  the  process  starts 
at  time  0. 

^  30 

Printer  =  accept  — *  print  — »  Printer 

Where  print. Engage- accept. Engage  <  60 

W  is  the  constraint  print. Engage- accept. Engage  ^  60,  which  means  V  i  :  N  • 
print. ENGAGE^-accept.ENGAGEi  ^  60.  The  following  is  one  possible  execution 
sequence. 

30 

( accept  — »  print  —>  Printer ,  0, 

{print. Engage- accept. Engage  ^  60},  {(Start,  0)})  22 

30 

( accept  — ►  print  — >  Printer ,  10, 

{print. Engage- accept. Engage  ^  60},  {(Start,  0)}>  ac^>t 
(Stop  >{30}  print  — *  Printer,  10,  {print. Engage- accept. Engage  ^  60}, 

{(Start,  0),  ( accept. Engagei,  10)})  22 
{print  — ■»  Printer,  40,  {print. Engage  —  accept. Engage  ^  60}, 

{(Start,  0),  {accept. Engagei,  10)})  22 
{print  — »  Printer,  60,  {print. Engage  —  accept. Engage  ^  60}, 

{(Start,  0),  {accept. Engagei,  10)})  P 
{Printer,  60,  {print. Engage  —  accept. Engage  ^  60} 

{(Start,  0),  {accept. Engagei,  10),  {print. Engagei,  60)}) 


In  this  execution,  event  accept  is  firstly  engaged  at  10,  we  insert  ( accept. ENGAGEjlO) 
to  Tss.  It  is  not  likely  for  event  print  to  be  firstly  engaged  after  40  seconds  while 
it  is  enabled,  where  print. Engage^  will  be  greater  than  70,  since  it  is  guarded 
by  print. Engage- accept. Engage  St  60.  □ 

Healthiness  Conditions  As  illustrated  in  the  last  section,  each  process  is 
attached  with  a  Where  clause,  which  restricts  the  set  of  timed  traces  of  the 
process.  The  constraints  associated  with  a  process  are  divided  into  two  groups, 
namely  the  explicit  ones  defined  in  the  Where  clause  and  a  set  of  implicit 
ones.  The  implicit  constraints  should  always  be  true,  i.e.,  a  set  of  healthiness 
conditions.  The  following  are  two  examples  of  such  healthiness  conditions.  The 
complete  list  of  healthiness  conditions  can  be  found  in  [7] . 

—  For  every  event  e  in  process  P,  e  must  be  engaged  between  the  starting  time 
and  ending  time  of  P.  Let  aP  be  the  alphabet  of  P. 

V  e  :  aP  •  P. Start  <  e. Engage  a  e. Engage  <  P.End 

—  Let  Pi  be  a  sub-process  of  P,  written  as  Pi  =4  P  ■  The  starting  time  of  Pi 
must  be  greater  than  or  equal  to  the  starting  time  of  P  and  the  its  ending 
time  must  be  less  than  or  equal  to  that  of  P. 


V P,  Pi  •  Pi  =4  P  =>  P. Start  <  Pj. Start  A  P8.End  <  P.End 


4  Verification  of  Timed  Planning 

In  order  to  apply  constraint  solving  technique  to  reason  about  systems  modeled 
in  the  extended  Timed  CSP,  we  need  to  firstly  encode  the  semantics  of  the 
processes  as  CLP  rules.  Once  we  encode  the  semantics  of  processes  as  CLP 
rules,  well-established  constraint  solvers  like  CLP  (1Z)  [14]  can  be  used  to  reason 
about  those  systems.  Operational  semantics  defined  in  Section  3.3  are  all  encoded 
systematically. 

The  very  initial  step  is  to  encode  the  syntax  the  extended  Timed  CSP  into 
CLP.  Note  that  this  step  can  be  automated  by  syntax  rewriting.  A  relation 
tproc{N ,  P,  W)  is  used  to  present  a  process  P  of  name  N  with  where  predicates 
W .  IT  is  a  set  of  wherePred  in  a  logical  conjunction  form.  For  instance,  W  = 
[Wl,  W2,  W3\  means  wherePred  =  IT1A  IT2A  IT3.  If  there  are  no  Where 
predicates  defined  for  this  process,  IT  is  the  empty  set.  For  instance,  the  syntax 
encoding  of  task  Kitchen  (Example  2)  is  as  follows. 

tproc{kitchen,  eventpreftx  {cook ,  eventpreftx (supply ,  kitchen)),  [  ]). 
tproc{counter ,  delay{order,  eventpreftx  {serve,  counter),  30), 

[leq{engage(serve) ,  engage(order))}) . 
tpoc{mc,  parallel  {kitchen,  counter), 

[geq{number{tr{mc),  supply),  number {tr {me),  order)), 
leq{minus  {number  {tr  {me),  supply),  number  {tr  {me),  order)),  5)]). 

where  relations  ‘leq,  geq,  minus,  number'  are  built-in  predicates  defined  in  our 
library,  which  represent  >,  — ,  J.’  respectively. 

Having  defined  the  corresponding  CLP  syntax  for  the  Timed  Planning  specifi¬ 
cations,  we  devote  the  rest  of  this  section  to  describe  how  the  operational  seman¬ 
tics  are  embedded  as  CLP  rules.  A  relation  of  the  form  tpos{P\,  T\,  E\,M,  P2,  T2,  E2) 
is  used  to  denote  the  timed  planning  operational  semantics,  by  capturing  both 
event  transition  relations  and  evolution  relations  with  a  set  of  constraints.  In¬ 
formally  speaking,  tpos{Pi,  T1:  E\,  M,  P2,  T2,  E2)  returns  true  if  the  process  Pi 
evolve  to  P2  through  either  a  time  evolution,  i.e. ,  let  T2  —  Ti  time  units  elapse 
(so  that  M  =  []),  or  an  event  transition  by  engaging  an  abstract  event  e  in¬ 
stantly  {M  =  e),  as  long  as  both  transitions  satisfy  the  Where  requirements 
stored  in  E\.  After  this  transition  relation,  the  local  environment  might  change 
to  E2  by  adding  more  predicates.  E\  (and  E2)  is  the  environment  of  the  system, 
which  consists  not  only  the  Where  predicates,  but  also  the  current  values  of 
the  variables  appeared  in  the  Where  predicates. 

We  define  the  tpos/7  1  relation  for  each  and  every  operator  of  the  extended 
Timed  CSP  according  to  the  semantics  presented  previously  in  Section  3.3. 

tpos{stop,  T 1,  E,  [],  stop,  T2,  E)  :  —D  >=  0,  T2  =  Tl  +  D. 

tpos{skip,  T,  El,  [termination],  stop,  T,  E 2)  :  —sat{E,  termination,  T,  E 2). 

tpos{skip,  Tl,  El,  [],  skip,  T2,  E2)  :  —D  >=  0,  T2  =  Tl  +  D,  sat{El,  Tl,  E2). 


1  tpos/7  indicates  the  relation  tpos  with  7  parameters,  same  for  sat/3  and  sat/4. 


The  only  transition  for  process  Stop  is  time  elapsing.  Process  Skip  may  choose 
to  wait  some  time  before  engaging  the  termination  event  which  is  our  choice  of 
representing  ■/  in  CLP.  Process  Skip  may  not  be  able  to  terminate  immediately 
since  there  might  be  some  constraints  involving  P.End  defined  in  the  Where 
clause.  The  relation  sat  is  required  to  be  evaluated  before  the  termination.  Re¬ 
lation  sat(E1,  A,  T,  E2)  and  sat(E1 ,  T,  E2)  are  used  to  test  whether  the  current 
state  fulfills  the  requirements.  Relation  sat / 4  handles  event  transition  and  sat /3 
handles  timed  transition.  The  sat/ 4  and  sat/ 3  rules  are  defines  as: 

sat  (El,  termination,  T,E  2)  :  —get_process(El,  N), 
insert(end(N ,  T),  El,  E2),  evaluate(E2) . 
sat(El,A,  T,E2)  :  —get_process(El,  N), 

insert  (engage/ A,  N,  T),  El,  E  2),  evaluate(E2) . 
sat(E  1,  T,E1)  :  —evaluate(El). 

The  first  rule  says  that  whenever  the  termination  event  has  been  engaged,  the 
predicate  P.End  =  T  need  to  be  validated  in  conjunction  with  all  the  current 
requirements  stored  in  El.  Once  it  has  been  proved  that  the  resultant  predicate 
is  not  contradiction,  we  append  this  predicate  to  the  current  set  of  predicates. 
The  second  rule  is  to  validate  the  case  when  an  event  is  engaged,  by  adding  the 
predicate  AEngage  =  T  to  the  environment.  The  last  rule  captures  the  timed 
transition  relation  by  evaluating  the  current  environment  with  the  current  time. 
Relation  get-process(E,  N)  is  to  find  the  current  named  process  being  executed. 
evaluate(E)  is  to  evaluate  the  current  requirements,  namely  the  constraint  store. 
The  detailed  definition  of  get_process / 2  and  evaluate /I  can  be  found  in  our  web 
site2. 

In  the  operational  semantics,  there  are  a  set  of  composition  operators  which 
are  more  complex  than  the  primitive  ones.  For  instance,  the  rules  associated 
with  the  semantics  of  alphabetized  parallel  composition  operator  Pi  x  \  \y  F2 
are  as  follows. 

tpos(para(Pl,  P2,  X,  Y),  T ,  El,  A,  para(P3,  P2 ,  X,  Y),  T,  E2) 

:  —  member  (A,  X),  not  (member  (A,  Y)), 

sat(El,  A,  T ,  E2),  tpos(P  1,  T,  El,  A,  P3,  T,  E2). 
tpos(para(Pl,P2,X,  Y),  T,  El,  A,  para(Pl,  PA,  X,  Y),  T,E2) 

:  —  member(A ,  Y),  not(member(A,  X)), 

sat(El,  A,  T,  E2),  tpos(P2,  T,  El,  A,  PA,  T,  E2). 
tpos(para(Pl,P2,X,  Y),  T,  El,  A,  para(P3,  PA,  X,  Y),  T,E2) 

:  —  member (E,  X),  member (E,  Y),  sat(El,  A,  T,E2), 

tpos(P  1,  T,  El,  A,  P3,  T,  E2),  tpos(P2,  T,  El,  A,  PA,  T,  E2 ). 

tpos(para(Pl,P2,X,  Y),  Tl,  E ,[},  para(P3,  PA,  X ,  Y),  T1  +  D,E) 

:  -  tpos(P  1,  Tl,  E,  [],P3,  Tl  +  D,  E),  tpos(P2,  Tl,  E,  [},  PA,  Tl  +  D ,  E). 

There  is  a  one-to-one  correspondence  between  our  rules  and  the  operators  which 
are  fully  defined  at  [7].  This  makes  the  soundness  of  our  rules  straightforward. 

http :  //www.  comp  .mis  .  edu.  sg/~zhangxi5/horae 
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We  have  implemented  a  prototype  reasoner  based  on  one  of  the  established 
CLP  solver,  namely  CLP(7\1).  CLP(7?.)  is  chosen  for  its  support  of  real  numbers 
and  thus  continuous  time  variables.  A  number  of  theories,  libraries  and  shortcuts 
have  been  developed  for  easy  querying  and  proving.  This  section  is  devoted  to 
various  proving  we  may  perform  over  systems  modeled  using  our  extended  Timed 
CSP.  We  discuss  two  main  ones  here.  The  first  one  is  feasibility  checking,  which 
answers  the  schedulability  problem.  The  other  is  safety  and  liveness  checking. 


4.1  Feasibility  Checking 

After  specifying  the  tasks  using  the  extended  Timed  CSP  in  CLP  (TV),  the  very 
first  task  is  to  check  whether  the  tasks  are  feasible  before  simulation  or  reasoning 
of  the  system.  Feasibility  checking  is  necessary  because  there  might  be  a  conflict 
among  the  set  of  Where  clauses  of  a  system,  which  potentially  invalidates  any 
proving  result.  To  perform  this  task,  the  conjunction  of  the  Where  predicates 
and  the  healthiness  conditions  are  checked. 

The  output  of  the  feasibility  checking  is  either  yes  if  the  tasks  are  feasible 
or  else  no.  In  case  the  tasks  are  infeasible,  i.e.,  there  is  no  way  to  satisfy  all 
the  constraints,  a  minimum  set  of  predicates  which  conflict  each  other  can  be 
generated  so  as  to  facilitate  user  correction  easily.  We  use  the  CLP  (TZ)  predicate 
feasibility —checking (N ,  S)  to  fulfill  this  purpose,  where  N  is  the  name  of  the 
process  that  is  to  be  checked,  and  S  is  the  minimum  conflict  set.  If  the  process  N 
is  a  feasible  process  feasibility —checking / 2  returns  false,  otherwise  the  minimum 
conflict  set  S  is  generated  and  returned. 

feasibility -checking  (N ,  S)  :  —  get-where{N ,  W),  min-Consstore(W ,  S). 

min-Consstore{W ,  S)  :  —  find -min  (1,  W,  S). 

find-min(N,  W,  W)  :  — size(  W,  L),  L  <  N, !. 

ftnd—min(N,  W,  S)  :  — size(X,L),L  >=  N,  delete_at(N,  W,  WS), 

( satisfy(WS )—  >  find-min(N  +  1,  W,  S);  find-min(N ,  WS,  S )). 

Relation  min-Consstore(  W,  S)  is  to  generate  the  the  minimum  conflict  set  S 
of  W  if  W  |=  false.  It  is  performed  by  a  linear  scan  on  a  sequence  of  constraints. 
We  check  whether  after  removing  one  constraint,  the  constraints  store  becomes 
satisfiable  or  not.  If  it  does,  then  this  constraint  must  be  important  and  have 
to  be  put  back,  otherwise  it  can  be  discarded.  It  is  an  iterative  process  until  a 
minimum  set  is  found. 


4.2  Reasoning  about  Safety  and  Liveness 

Feasibility  checking  is  to  check  whether  the  tasks  modeled  in  Timed  Planning  are 
feasible.  Once  it  is  proven  to  be  feasible,  we  can  reason  about  safety  or  liveness 
properties  by  making  explicit  assertions. 

Relation  reachable(P,  Q,El,E2,  T 1,  T2,  Tr)  is  defined  to  explore  the  full 
state  space  if  necessary.  Informally,  it  states  that  “process  P  starts  at  T1  with 


environment  El  is  able  to  be  executed  to  Q  at  T 2  with  environment  changed 
to  E2  via  trace  Tr” . 


reachable(P ,  P ,  T ,  T,  []). 

reachable(P,  Q,  El,  E2,  T 1,  T2,  iV)  :  -tpos(P,  T 1,  £1,  A  PI,  T3,  P3), 

(A  =  t(_);  A  ==  taw,  A  =  reccall(-)),  not  table(Pl), 
assert  {table{P 1)) ,  reachable(Pl,  Q,  E3,  E2,  T3,  P2,  TV). 
reachable(P ,  Q,  El,  E2T1,  T2,  [E  |  TV])  :  -tpos(P,  T 1,  El,  A,  PI,  T 3,  E3), 
not{A  =  i(_);  A  ==  tau]  A  =  reccall(-)),  not  table(Pl), 
assert(table(Pl)) ,  reachable{Pl ,  Q,  P3,  E2,  T3,  P2,  TV). 

reachable/ 7  is  used  to  build  assertions  for  various  property  checking.  The  first 
property  of  interest  is  to  find  one  particular  feasible  schedule  for  the  tasks, 
provided  that  the  tasks  are  feasible.  Relation  instance{P ,  Ins)  is  able  to  generate 
such  feasible  schedule  Ins  of  process  P. 

instance(P ,  Ins)  :  — not  feasibility -checking (TV ,  _),  init_Env{N ,  E), 
reachable(P ,  _,  E,  _,  0,  _,  Ins). 

where  P  specifies  the  tasks  and  Ins  is  a  scheduling. 

One  property  of  special  interest  is  deadlock-freeness.  Relation  deadlock(P ,  Tr) 
is  used  to  check  the  deadlock-freeness  property,  by  trying  to  find  a  counterex¬ 
ample  where  P  is  deadlocked  at  some  trace  Tr. 

deadlock (P ,  Tr)  :  —init-Env(P,  E),reachable(P,  PI,  E,  E2,0,  T2,  Tr), 
(tposiyPl,  T2,  E2,  [«(_)],  Ql,  T3,  E3)  -> 

not(tpos(Ql,  T3,  E3,  A,_,_,_),  not  A  =  [t (_)]); 
not(tpos(P  1,  T 2,  El,  A,  Ql,  T 3,  _),  not  A  =  [£(_)])). 

It  states  that  a  process  P  at  time  0  may  result  in  deadlock  if  it  can  evolve  to  the 
process  expression  Q  at  time  T 2  where  no  event  transition  is  available  neither 
at  T 2  nor  at  any  later  moment.  The  last  line  outputs  the  trace  which  leads  to  a 
deadlock.  Alternatively,  we  may  present  it  as  the  result  of  the  deadlock  proving. 
Note  that  the  above  is  different  from  the  deadlock  checking  for  standard  Timed 
CSP  as  presented  in  [6].  Here  the  Where  clauses  at  each  step  must  be  fulfilled. 

In  general,  a  deadlock-free  Timed  CSP  process  may  become  a  non  deadlock-free 
process  after  it  is  enriched  with  certain  Where  clauses.  It  is,  however,  also 
possible  for  a  non  deadlock-free  process  to  become  deadlock-free. 

We  can  also  find  the  execution  duration  of  an  specific  event,  more  specifically, 
the  range  of  time  that  the  event  is  able  to  be  engaged.  Relation  engage_time(P,  E,  R) 
is  defined  for  the  purpose,  which  is  to  find  the  range  R  of  the  engage  time  of 
event  E  in  process  P.  The  detailed  definition  for  all  relations  can  be  found  in 

[7]- 


engage-time(P ,  E ,  [])  :  —not  happen-at(P ,  E ,  _) . 
engage_time(P,  E,  R)  :  —happen_at(P ,  E,  T),  union(R,  T,  PI), 

engage— time{P ,  E,  PI). 


where  R  is  the  range  of  engaged  time  of  event  E  in  process  P  which  is  generated 
after  executing  the  relation.  For  instance, 


P  =  a  b  A  Skip  ||  c  ^  b  Skip 

Where  End  -  Start  <  15  A  3  <  a. Engage  <  7 

The  range  of  engage  time  of  event  b  can  be  found  by  executing  the  following 
query  ?  —  engage-time(p ,  b,  R).  It  returns  result  in  the  binding  R  =  [ b_engage  > 
8,  b_engage  <  9],  which  indicates  b. Engages  [8,  9]. 


5  Case  Study:  The  Pearl  Harbor  Attack 

The  attack  on  Pearl  Harbor  was  a  surprise  military  strike  conducted  by  the 
Japanese  navy  against  the  United  States’  naval  base  at  Pearl  Harbor,  Hawaii, 
on  the  morning  of  Sunday,  December  7,  1941,  later  resulting  in  the  United  States 
becoming  militarily  involved  in  World  War  II.  It  was  a  carefully  planned  attack 
by  the  Japanese  Navy  which  consisted  of  two  aerial  attack  waves  totaling  353 
aircraft,  launched  from  six  Japanese  aircraft  carriers. 

We  studied  some  documents  on  plans  and  preparations  of  the  attack  from  [9] 
and  formalize  the  model  of  this  attack  using  the  Timed  Planning  specifications. 
The  whole  mission  consists  of  several  forces:  air  attack  force,  screening  unit, 
support  force,  patrol  unit,  midway  bombardment  unit,  reconnaissance  unit  and 
supply  force,  where  each  force  has  its  own  strength  and  duty. 


Air  Attack  Force 

“  Air  attacks  will  be  carried  out  by  launching  the  first  attack  units  230 
nautical  miles  due  north  of  Z  point  at  0130  hours  (05:30am  honolulu  time)  X 
Day  (the  day  of  the  outbreak  of  hostilities),  and  the  second  attack  unit  at  200 
nautical  miles  due  north  of  Z  point  at  0245  hours.... 

Carrier  Striking  Task  Force  Operation  Order  No. 3  23  Nov  1941 ” 

The  air  force  attack  consists  of  two  waves,  we  name  take  as  FirstAttack  and 
SecondAttack .  According  to  their  plan,  the  air  force  advanced  their  destination 
20  hours  before  the  attack.  We  model  the  air  force  attack  as  follows,  where  we 
use  0  to  denote  00:00am  such  that  90  means  1:30  am  and  so  on. 

FirstAttack  =  launching. 24  — >  arrive. oahu  — >  attack  — >  return  — >  Skip 

Where  launching. Engage  =  90  A  330  ^  return. Engage  ^  360 
FirstAttack  =  launching .24  — >  arrive. oahu  — >  attack  — >  return  — >  Skip 

Where  launching. Engage  =  165  A  405  sc  refitrn.ENGAGE  ^  435 
AirAttackForce  =  advance  ( FirstAttack  |||  SecondAttack) 

According  to  the  document,  for  both  attack,  the  aircrafts  would  return  after 
4  hours  and  within  4  and  half  hours  of  the  start  of  each  attack,  launching. 24 
denotes  the  aircrafts  are  launching  at  speed  of  24  knots. 


The  Midway  Bombardment  Unit  The  midway  bombardment  unit  will  de¬ 
part  from  Tokyo  Bay  and  after  after  refueling,  secretly  approach  midway.  It  will 
arrive  on  the  night  of  X  Day  and  shell  the  air  base.  The  unit  will  withdraw  and, 
after  refueling,  return  to  the  western  part  of  the  Inland  Sea.  We  model  the  task 
of  this  unit  as  MidwayBUnit. 

MidwayBUnit  =  refuel  — >  depart  — >  arrive  — >  shell  — >  refuel  — >  return  — >  Skip 
Where  arrive. Engage  >  1080 

where  constraint  arrive. Engage  ^  1080  captures  the  idea  that  the  unit  would 
arrive  at  that  night. 


The  Reconnaissance  Unit  This  unit  consists  of  different  kind  of  reconnais¬ 
sances. 

—  Immediate  Pre-attack  Reconnaissance:  Two  reconnaissance  seaplanes  will 
take  off  at  0030  hours,  X  Day,  secretly  reconnoiter  Pearl  Harbor  and  La- 
haina  Anchorage  and  report  the  presence  of  the  enemy  fleet. 

—  Post- Attack  Reconnaissance:  Before  returning  to  the  carrier,  after  the  attack, 
an  element  of  the  fighters  will  fly  as  low  as  possible  to  observe  and  determine 
the  extent  of  the  damage  inflicted  upon  the  enemy  aircraft  and  ships. 


IPAReconn  =  takeoff  — >  (launch. pearlHarbor  — >  reconnoiter  — >  report  — >  Skip 
||  launch. lahaina  — >  reconnoiter  — >  report  — >  Skip); 
return  — >  Skip 

Where  takeoff  .Engage  =  30 
PAReconn  =  takeoff  — >  observe  — >  report  — >  return  — >  Skip 


Reconnaissance  =  IPAReconn  |||  PAReconn 

The  takeoff  time  of  the  Post-Attack  Reconnaissance  depends  on  the  com¬ 
pleteness  of  the  main  attack,  so  the  constraint  on  the  engage  time  of  takeoff  will 
be  attached  on  a  upper  level  process. 

We  model  the  task  of  each  force  as  a  process,  the  Pearl  Harbor  Attack  on  X 
Day  is  a  composition  of  all  sub  tasks. 

PearlHarbor  Attack  =  AirForceAttack  |||  MidwayBUnit  |||  Reconnaissance 
||  Supply  HI  screening  |||  Patrol 
Where  PAReconn. Start  ^  AirForceAttack. End 


The  documents  recorded  that  in  the  initial  plan,  the  Japanese  Navy  con¬ 
sidered  an  assault  plan  in  case  the  surprise  attack  does  not  succeed.  But  later 
they  determined  not  to  conduct  this  assault  plan  because  at  that  time  they  had 


complete  confidence  in  the  strength  of  the  fighter  units.  If  the  assault  plan  is 
included  in  the  whole  plan,  the  model  will  be  as  follows: 


PearlF[ arbor Attack2  =  (Air Force  Attack  |||  MidwayBUnit  |||  Reconnaissance 
j||  Supply  HI  screening  |||  Patrol ) 

V  fail  — ►  AssaultPlan 

Where  PAReconn.  Start  ^  Air  Force  Attack. Find 


6  Job-shop  Scheduling 

In  this  section,  we  show  how  the  problem  of  job-shop  scheduling  can  be  modeled 
and  solved  using  the  Timed  Planning  specifications.  We  model  both  determin¬ 
istic  job-shop  scheduling  problem  as  well  as  the  preemptive  ones,  which  to  our 
knowledge  cannot  be  modeled  and  solved  using  purely  Timed  CSP  specifications. 

6.1  Job-Shop  Scheduling  Problem 

The  job-shop  scheduling  problem  (JSSP)  is  a  generic  resource  allocation  problem 
in  which  common  resources  ( “machines” )  are  required  at  various  time  points  (and 
for  given  durations)  by  different  jobs.  The  goal  is  to  find  a  way  to  allocate  the 
resources  such  that  all  the  jobs  terminate  as  soon  as  possible,  which  is  a  schedule 
with  the  minimum  time  interval  to  finish  all  jobs.  The  difference  between  a 
deterministic  and  a  preemptive  job-shop  scheduling  problem  is  for  the  latter 
case,  jobs  can  use  a  machine  for  some  time,  stop  for  a  while  and  then  resume 
from  where  they  stopped.  We  define  both  problems  formally  as  follows. 

Definition  4.  (Job-shop  scheduling  problem)  Given  a  set  of  O  ol  operations,  a 
set  Ai  of  m  machines,  and  a  set  J  of  n  jobs.  For  each  operation  v  £  O  there  is 
a  processing  time  p(u)  G  N,  a  unique  machine  M(v)  £  M  on  which  it  requires 
processing,  and  a  unique  job  J(v)  £  J  to  which  it  belongs.  □ 

The  difference  between  deterministic  and  preemptive  job-shop  scheduling 
problem  is  the  feasible  schedule. 

Definition  5.  (Feasible  Schedules  for  Deterministic  Job-Shop  Problem)  A  sched¬ 
ule  is  a  function  S  :  O  — *  N  that  for  each  operation  v  defines  a  start  time  S  (u) . 
A  schedule  S  is  feasible  if 

1.  Covering  : 

Wu  £  O  :  S(u)  >  0, 

2.  Non -Preemption  : 

V  v,u>  £  0,(v,ui)  £  A  :  S(u)  +  p(v)  ^  S(co) 

3.  Mutual -Exclusion  : 

Vr,uGO,v/w,M(r)  =  M (co)  : 

S (v)  +  p(v)  ^  S ( to )  or  S (lo)  +  p(co)  Sj  S (v) . 

The  problem  is  to  find  an  optimal  schedule,  i.e.,  a  feasible  schedule  of  minimum 
processing  time. 


Definition  6.  (Feasible  Schedules  for  Preemptive  Job-Shop  Problem)  Let  T{0,  i)  £ 

N  be  processing  time  of  the  ith  step  at  which  operation  O  executes.  A  schedule  is 
a  relation  S  C  O  x  N  x  T  so  that  (v,  st,  t)  £  S  indicates  that  operation  v  starts 
to  process  on  time  st  and  processes  for  time  t.  A  schedule  S  is  feasible  if 

1.  Ordering  : 

O,  (v,u))  £  A, 

{y,  st ,  t)  £  S,  (u>,  st',  t')  £  S  :  st  +  t  <  st'  +  t' 

2.  Covering  : 

Vv£0:Y,(„,st,t)eSt  =  P(v) 

3.  Mutual -Exclusion  : 

V  u,  to  £  O,  v  ^  U),  (v,  st,  t )  £  S,  (lo,  st',  t')  £  S, 

M[y)  =  M (w)  :  st  +  t  <  st'  or  st'  +  t’  <  st. 

Consider  M={mi,m2}  and  two  jobs  J 1  =  (m2, 4)  and  J2  =  (mi,  3),  (m2, 4),  (m3,  6). 
The  schedules  Si,  S2  and  S3  are  depicted  in  Figure  3.  The  length  of  S2  13  is  the 
optimal  schedule  for  a  deterministic  problem  while  S3  which  is  11  is  the  optimal 
schedule  for  a  preemptive  problem. 
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Fig.  3.  The  Gantt-Chart  representations  of  three  schedules 


6.2  Modeling  in  Timed  Planning 
Deterministic  Job-shop  Scheduling  Problem 

Definition  7.  (Timed  Planning  for  a  Job)  Let  J1  =  {o\, ...,  on)  be  a  job,  which 
is  a  chain  of  operations  (ordered)  on  a  set  of  machine  M.  Its  associated  process 
presentation  Pi  is 

~  p(oi)  p(o2)  p(ok)  _ 

Pi  =  mi  — >  m2  — >  ...rrik  — >  skip 

where  event  mj  in  Pi  denotes  operation  Oj  of  job  J1  starts  to  process  on  machine 
mj  where  mj  =  M(oj).  p{oj)  is  the  processing  time  required  for  Oj  on  mj.  Hence 


the  delay  process  m: 


P(Oj) 


mj+i 


p{oj+ 1) 


denotes  that  Oj  must  process  at  machine 


mj  /or  p(oj)  time  units;  then  Oj+i  can  staid  to  process  which  do  not  need  to  start 
immediately. 


Definition  8.  (Mutual  Exclusion  Constraints)  Let  J  =  {J1,...,  J"}  he  a  job- 
shop  specification  and  V  =  {Pi, Pn}  he  a  set  of  timed  planning  processes 
defined  for  each  job. 


mutual-  exclusion(P)  = 

VPi,Pj  e  p,  M  j,  Vm  e  £  p,  u  £  P3  . 

m  A  P[  Pi  A  m  -L  P)  =<I  Pj  => 

Pi. m. Engage  +  u  <  Pj.m. Engage  V 
Pj. m. Engage  +  /  ^  Pj.m. Engage 


Definition  9.  (Timed  Planning  for  Job-Shop  specifications)  Let  J  =  {  J, Jn} 
be  a  job-shop  specification  and  V  =  {Pi,  ■■■,  Pn}  be  a  set  of  timed  planning  pro¬ 
cesses  defined  for  each  job.  The  timed  planning  presentation  for  the  job-shop 
specification  J  will  be  an  interleaving  of  all  processes  Pi  with  the  non-delay  and 
mutual  exclusion  constraints: 

JSSP  =  |||o<i^n  Pi  Where  mutual -exclusion(JSSP) 

For  every  complete  execution  of  JSSP  (which  terminates),  its  associated  sched¬ 
ule  S  is  a  feasible  schedule.  An  optimal  schedule  is  a  trace  of  JSSP  with  the 
minimum  ending  time  min(JSSP. End). 


Preemptive  Job-shop  Scheduling  Problem 

Definition  10.  (Timed  Planning  for  a  Preemptive  Job)  Let  J1  =  (oi, on)  be 
a  job,  which  is  a  chain  of  operations  (ordered)  on  a  set  of  machine  A 4.  Each 
operation  Oj  should  process  on  machine  mj  for  p{oj)  time  unit.  Its  associated 
process  presentation  for  Oi  is: 


Oi  —  X  •  ms  — >  me  — >  Skip;  X  □  Skip 

Where  me.  Engage  —  ms.  Engage  ^  p(o*)  A 

me. Engage -me. Engage  =  p(oi)  End  <  oo 

Event  ms  denotes  operation  Oj  starts  to  process  on  its  corresponding  machine 
m,  me  denotes  it  leaves  m.  Expression  Y)  rae. Engage  —  ms. Engage  represents 
the  total  time  o.j  processes  on  m. 

The  associated  process  presentation  Pj  for  each  job  is 

Pi  =  O^-,  Oi2;  Oik 

Definition  11.  (Mutual  Exclusion  Constraints)  Let  J  =  { J1, ...,  J"}  be  a  job- 
shop  specification  and  V  =  {Pi, ...,  Pn{  be  a  set  of  timed  planning  processes 
defined  for  each  job. 


mutual -exclusion(P)  = 

V Pi,  Pj  €  P,i  j, M{ms,  me}  C  P;  n  Y)  Pj  • 

(gX  •  ms  — >  me  — >  ...  =$1  Pi  A 
/iX  •  m,  — >  TOe  — >  ...  =5!  Pj)  =*> 

Pi. me. Engage  ^  Pj.ms. Engage  V 
Pj.me. Engage  ^  Pi. ms. Engage 

Definition  12.  (Timed  Planning  for  Preemptive  Job-Shop  specifications)  Let 
J  =  {J1,...,  J"}  6e  a  job-shop  specification  and  V  =  {Pi,...,P„}  be  a  set  of 
timed  planning  processes  defined  for  each  job.  The  timed  planning  presentation 
for  the  preemptive  job-shop  specification  J  will  be  an  interleaving  of  all  processes 
Pi  with  mutual  exclusion  constraints: 

PJSSP  =  |||0<i<n  Ps 

Where  mutual -exclusion(P  JSSP) 


6.3  Extended  Job-shop  Scheduling 

Since  Timed  Planning  is  very  flexible  to  specify  system  behaviors,  with  opera¬ 
tional  behaviors  and  critical  timing  constraints,  those  extended  job  shop  schedul¬ 
ing  problems  with  several  additional  features  that  are  often  specified  in  task 
scheduling  problems  can  be  easily  and  naturally  modeled  and  solved  using  Timed 
Planning.  In  this  project,  we  mainly  focus  on  the  compositional  behaviors  and 
the  deadline  and  relative  times  extension.  To  our  knowledge  no  other  approaches 
are  capable  for  those  extensions. 


Compositional  Job  Behaviors  In  traditional  job-shop  scheduling  problems, 
all  jobs  are  executed  synchronously,  which  means  that  they  are  enabled  at  the 
same  time.  In  our  approach,  jobs  can  be  constructed  in  a  more  general  way,  for 
example,  we  can  specify  choices  of  jobs,  sequences  of  jobs  and  interruption  of  one 
job  by  another  job,  by  using  the  composition  operators  of  Timed  Planning.  For 
example,  a  job-shop  scheduling  problem  consists  of  4  jobs  J  =  { J1,  J2,  J3,  J 4}, 
where  either  J 1  or  J 2  is  running  concurrently  with  J3  which  is  interrupted  by 
J4  in  10  time  units  after  execution.  This  scheduling  problem  can  be  specified  as 
follows: 

JSSP  =  (PI  □  P2)  HI  (P3  V{10}  P4) 

Where  mutual- exclusion(  JSSP)  A  non-delay 

In  our  interpretation,  jobs  can  communicate  with  each  other  through  channels. 
A  job  PI  can  activate  another  job  P 2  after  some  time  t  or  after  PI  finishes  its 
first  ith  operations.  A  job  can  also  stop  a  job  for  some  time  units. 

An  extended  job-shop  scheduling  problem  consists  of  2  jobs  J1,  J2,  J 1  = 
(1,  2),  (0, 3),  (2,  5),  J2  =  (2, 3),  (0, 3),  (1, 3).  J 1  will  activate  J2  after  J1  finishes 
its  first  operation.  The  Timed  Planning  model  of  this  problem  is  specified  as 
follows  where  a  channel  naming  c  is  used  to  fulfill  this  purpose. 


PI  =  1  —>  c\ activate  — *  0  2  Skip 
P2  =  c? activate  ->  2  4o-^>  1  Skip 
JSSP  =  Pi  HI  P2 

Where  mutual- exclusion(JSSP)  A  non- delay 


Deadlines  and  Relative  Timing  Constraints  Another  extension  of  job- 
shop  scheduling  problem  is  that  we  can  specify  the  deadline,  relative  timing 
constraints  of  each  job.  Those  constraints  can  be  naturally  handled  in  Timed 
Planning  by  using  its  Where  predicate.  We  formulate  the  constraints  into  3 
rules  as  follows: 

Rule  1  Every  operation  Oi  must  be  imperatively  terminate  before  time  d(oi) 

V  Oi  eO  •  S{oi)  +p(oi)  <  d(oi) 

Rule  2  Every  jobJlmust  be  terminate  before  time  d{  Jl) 

V  Ji  e  J  •  J\ End  <  d{P) 

Rule  3  Relative  timing  constraints  between  operations 
3  Oi,  Oj  e  O  •  p(oi)  ©  p(oj)  <  t  ,©€{+,-} 

6.4  Experiments 

We  test  ten  problems  among  the  bench  marks  of  the  job-shop  scheduling  prob¬ 
lems  on  Windows  XP  with  a  2.0  GHz  Intel  CPU  and  1  GB  memory.  In  Table  2 
we  compare  our  best  result  on  the  problems  with  the  result  reported  in  Table  15 
of  the  survey  paper  [17],  as  well  as  the  best  result  among  randomly  generated 
solutions  for  each  problem. 

7  Case  Study:  Timed  Reminding  System 

Timed  Reminding  System  is  a  specific  application  of  the  Timed  Planning  speci¬ 
fication,  where  some  features  cannot  be  fully  modeled  using  purely  Timed  CSP 
specification.  For  example,  reminds  the  elderly  to  take  medication  at  least  30 
minutes  after  each  meal,  but  cannot  take  more  than  once  within  6  hours. 

In  this  work,  we  provide  a  template  of  modeling  timed  reminders.  Firstly,  we 
classify  reminders  into  four  different  types  each  of  which  has  different  models 
and  parameters. 

1.  Timed-based  Prompting 

—  Timed  fixed  prompting  services 

—  Timed  related  prompting  services  (can  be  delayed  within  certain  time) 

2.  Event-based  Prompting 

—  Event  urgent  prompting  services:  triggered  by  events  and  need  to  be 
prompt  immediately. 

—  Event  related  prompting  services:  triggered  by  events,  but  can  be  delayed 
up  to  an  acceptable  delay  time,  or  must  be  delayed  after  an  min_delay 
time. 


1  Problem 

Timed  Planning 

Random 

Opt 

name 

ttj 

#m 

time(s) 

length 

deviation 

length 

deviation 

length 

FT10 

10 

10 

18 

1001 

7.63% 

1761 

89.35% 

930 

LA02 

5 

10 

2 

720 

9.90% 

1056 

61.68% 

655 

LA19 

10 

10 

0.2 

902 

7.12  % 

1612 

91.45% 

842 

LA21 

15 

10 

102 

1104 

5.54% 

2339 

123.61% 

1046 

LA24 

15 

10 

66 

1007 

7.58% 

2100 

124.00% 

936 

LA25 

15 

10 

19 

1098 

12.38% 

2209 

126.10% 

977 

LA27 

20 

10 

25 

1441 

16.68% 

2809 

127.45% 

1235 

LA29 

20 

10 

112 

1357 

17.79% 

2713 

135.50% 

1152 

LA36 

15 

15 

35 

1341 

5.57% 

2967 

133.90% 

1268 

LA37 

15 

15 

56 

1489 

6.58% 

3188 

128.20% 

1397 

Table  2.  The  result  for  the  ten  hard  bench  marks  deterministic  job-shop  scheduling 
problems.  The  first  three  columns  give  the  problem  name,  no.  of  jobs  and  no.  of  ma¬ 
chines.  Out  results  (time  in  seconds,  length  of  the  best  schedule  and  the  deviation)  ap¬ 
pears  next.  The  following  two  columns  shows  the  best  out  of  2000  randomly-generated 
solutions,  followed  by  the  optimal  result  of  each  problem 


7.1  Modeling  and  Specification 

In  this  reminding  system,  locations  of  the  participant  are  modeled  as  global 
variables  which  can  be  of  type  boolean,  integer,  string  or  tuple.  We  abstract 
the  changes  of  the  variables  which  should  be  updated  by  the  environment.  The 
activities  of  the  participant,  which  should  be  detected  by  some  sensing  system, 
are  modeled  as  events ,  such  as  getup,  leaving,  take-medication,  pick-phone  and 
etc. 

Timed  fixed  reminders  (TFR)  Timed  fixed  reminders:  The  prompting  is 
issued  strongly  at  defined  time  so  that  the  subject  understands  the  urgency  of 
executing  certain  activity,  e.g., 

—  get  up  at  7  a.m. 

—  catch  flight  at  11:30  a.m. 

—  go  to  attend  lecture/meeting/seminar  at  2p.m. 

Timed  fixed  reminders  can  be  modeled  as  processes  whose  starting  time  and 
prompting  time  must  be  exactly  as  the  required  time. 

TFR(t)  =  [ guard\prompt  — >  Skip 

Where  calendar -time(c,  Start). time  =  st  A 
prompt.  Engage  =  Start 

Example  4-  The  reminder  which  wakes  up  the  elder  at  7  a.m.  would  be: 

wake-up(( 7,0,0))  =  [athome  A  sleeping\prompt  — >  Skip 

Where  calendar -time(c,  Start). time  =  (7,0,0)  A 
prompt.  Engage  =  Start 


Timed  related  reminders  (TRR)  Timed  related  reminders:  prompting  is 
related  to  a  time,  but  can  be  delayed  within  an  acceptable  time,  e.g., 

—  Start  to  cook  dinner  between  5  p.m  and  5:30  p.m. 

—  Start  to  preparing  tutorials/lectures  at  3p.m. 

At  a  specific  time  t,  this  reminder  is  enabled,  but  it  do  not  need  to  prompt 
immediately  if  there  are  other  reminders  prompting.  It  need  to  be  prompted 
within  a  acceptable  delay  d 

TRR  =  [guard]prompt  — >  Skip 

Where  calendar -time(c,  Start)  ^  st  A 

calendar -time(c,  promp. Engage)  ^  st  +  dt 

Example  5.  Remind  the  elderly  to  start  preparing  his  dinner  at  around  5:30  p.m. 
to  5:30  p.m.  every  day  if  he/she  is  at  home. 

prep -dinner ((17 , 0, 0),  (17, 30, 0))  =  [athome  A  ~^sleeping\prompt.  — >  Skip 

Where  calendar -time(c,  Start). time  ^  (17,0,0) 
A  prompt. Engage  <  (17, 30, 0) 

Event  urgent  reminders  (EUR)  Event  urgent  reminders:  reminders  trig¬ 
gered  by  event,  which  must  be  prompt  as  soon  as  the  event  is  engaged. 

—  turnoff  the  stove  after  cooking 

—  bring  the  key  while  going  out 

Event  urgent  reminders  can  be  modeled  as  processes  whose  first  event  is  the 
triggering  event. 

EUR  =  trigger-event  — »  [guard]prompt  —>  Skip 

Where  trigger-event. Engage  =  prompt. Engage 

Example  6.  Remind  the  elderly  to  turnoff  the  stove  after  he  finishes  cooking. 

turnoff  stove  =  cooking-end  — >  prompt  — >  Skip 

Where  cooking-end. Engage  =  prompt. Engage 

Event  related  reminders  (ERR)  Event  related  reminders:  prompting  is  trig¬ 
gered  by  an  event,  but  can  be  delayed  within  a  accepted  time,  or  must  be  delayed 
after  a  certain  time,  e.g., 

—  wash  hands  after  toilet  within  3  minutes. 

—  take  medication  after  30  minutes  of  lunch. 

ERR  =  trigger-event  [ guard]prompt  — >  Skip 

Where  prompt. Engage  sC  trigger-event. Engage  +  dt 

Example  7.  Remind  the  elderly  to  wash  hand  after  he  finishes  the  toilet  in  3 
minutes. 

Wash-hand  =  finish-toilet  — >  prompt  — >  Skip 

Where  prompt.  Engage  ^  finish-toilet  .Eng  age  +  3  minute 


Daily/  Weekly  reminders  The  reminders  that  will  prompt  at  a  specific  time 
every  day,  or  every  week  with  some  conditions.  For  example,  the  wake  up  re¬ 
minder  which  will  prompt  8a.m.  every  weekdays.  The  attending  lecture  reminder 
which  will  prompt  every  10a.m.  every  Monday  if  not  public  holidays. 

Then  we  need  other  techniques  (rules)  to  identify  that  whether  today  is 
weekdays  or  weekends  or  public  holidays.  We  have  two  alternative  options: 

—  get  the  information  of  whether  today  is  weekdays  or  weekends  from  the 
environment  by  channels  and  abstract  the  details 

—  Maybe  can  use  Calendar  Logic  to  calculate  those  information  in  our  system. 
In  my  opinion,  Ontology  can  be  a  good  candidate  for  modeling  Calendar 
Logic. 

Daily  promoting  services:  prompt  at  time  t  everyday. 

Daily -Reminder  =  Reminder ;  Wait  l day',  Daily -Reminder 

Where  calendar -time(c,  Reminder. Start). time  =  t 

Daily  promoting  services:  prompt  at  time  t  everyday,  except  Saturday  and  Sun¬ 
day 


Daily -Reminder  =  Reminder ;  Wait  l  day',  Daily -Reminder 

Where  1  ^  calendar -time{c,  Reminder. Start). week  ^  5 
A  calendar -time{c,  Reminder  .Start),  time  =  t 


7.2  Priorities 

In  the  Timed  Reminding  System,  reminders  have  different  priorities.  Whenever 
more  than  one  reminders  are  enabled  at  the  same  time,  the  one  with  the  highest 
priority  will  be  triggered  and  the  others  will  be  suspended. 

In  our  settings,  we  introduce  a  new  variable  e.Pri  which  records  the  priority 
value  of  event  e.  Whenever  more  than  one  event  are  enabled,  if  the  priorities 
of  all  events  are  precisely  specified,  then  the  one  with  the  highest  priority  is 
engaged.  If  only  some  of  the  events  have  priority,  then  all  unspecified  events  and 
the  one  with  the  highest  priority  can  be  engaged. 

We  define  both  operational  and  clenotational  semantics  of  the  priority. 


7.3  Elderly  Reminding  System 

The  Elderly  Reminding  System  is  an  instance  of  the  Timed  Planning  System, 
which  helps  the  dementias  doing  daily  activities  such  as  take  medication  at  the 
right  time,  remind  them  prepare  lunch,  turn  off  stove  after  cooking  and  etc. 

In  this  system,  we  consider  the  following  reminders: 

—  wake  up  reminder  (Timed  fixed  reminder) 

—  brush  teeth  (Timed  related  reminder) 

—  meal  preparation  (Timed  related  reminder) 


—  making  phone  calls  (Timed  related  reminder) 

—  appointment  (Timed  related  reminder) 

—  turn  off  stoves  (Event  urgent  reminder) 

—  taking  medication  (Timed  related  reminder) 

—  bring  keys  while  going  out  (Event  urgent  reminder) 

—  wash  hands  after  toilet  (Event  related  reminder) 

Assumptions:  the  time  stamp  00:00  a. nr.  is  set  to  be  0.  Hence  1:00  a.m.  is 
60,  2:00  a.m.  is  120,  and  so  on. 

We  need  to  define  a  set  of  global  variables  to  keep  the  status  of  the  elderly. 

cithome  :  boolean 
sleep  :  boolean 
goingout  :  boolean 
bringkey  :  boolean 
washhand  :  boolean 

Wake  up  reminder  Wake  up  the  elderly  at  7:00  a.m. 

Wakeup  =  [at-home  A  sleeping\prompt-wakeup  — >  Skip 

Where  Start  =  calender -time(c,  Start)  =  (7,0,0) 

A  prompt_wakeup  =  Start 

Watch  TV  Reminders  the  elderly  to  watch  his  favorite  TV  program  at  10  am, 
which  is  timed  fixed  reminder. 

TV  =  [ athome\prompt-tv  — > 

Where  calender -time(c,  Start)  =  (10,0,0)  A  prompt-tv. Engage  =  Start 


Bring  key  Remind  the  elderly  to  bring  his  keys  while  going  out,  which  is  an 
event  urgent  reminder. 

channel:{bring_key}  is  a  sensor  detecting  whether  the  elderly  brings  his  keys  or 
not. 

channel  : {goingout} 

Key  =  goingoutlyes  — »  ([ ~^bringkey\prompt-bringkey  — »  Skip  □ 

[bringkey]  Skip) 

Where  prompt- bringkey  .Engage  =  goingoutlyes.  Engage 


Wash  hands  Remind  the  elderly  to  wash  hands  after  toilet,  if  the  elderly  does 
not  wash  his  hand  in  one  minute.  It  is  an  event  related  reminder, 
chanel: {toilet,  wash_hands} 

WashHands  =  toilet? finish  — >  (wash-hand? yes  — >  Skip  V{1}  prompt-washhand  — >  Skip) 
Where  prompt— washhand. Engage  —  toilet? finish. Engage  ^  5 


Prepare  Breakfast  Remind  the  elderly  to  start  preparing  his  breakfast  at 
around  8:30  a.nr.  to  9:00  a.m.  every  day  if  he/she  is  at  home. 

PrepareBreakfast  =  [ cithome  A  -> sleep\(prompt-breakfast  45^“te  Skip) 

Where  calender -time(c,  Start)  =  (8,30,0)  A 

prompt -breakfast.  Eng  age  <  Start  +  30 

Medication  Planner  Basic  system  requirements:  [20] 

1.  Never  prompt  outside  the  window:  within  a  certain  time  interval:  [st,  st+dt] 

2.  Don’t  prompt  if  pill  is  already  taken  within  the  current  window 

3.  Don’t  prompt  if  the  participant  is  not  at  home:  athome=true 

4.  Don’t  prompt  if  the  participant  is  sleeping 

5.  Don’t  prompt  if  participant  is  on  the  phone 

6.  Prompting  will  resume  if  the  participant  returns  home  before  the  window 
expires 

7.  Prompt  at  plan  2  if  participant  is  leaving 

8.  Wait  till  the  time  the  user  usually  takes  the  pill.  If  it  is  earlier  than  the 
recommended  pill  taking  time,  start  checking  for  plan  1  prompting  oppor¬ 
tunities  at  the  usual  pill  time. 

9.  If  only  less  than  20  minutes  left  till  the  window  expires,  start  prompting  at 
plan  1  disregarding  all  other  rules  (except  1-3) 

Two  kinds  of  prompting: 

Plan  1  Prompt  using  the  nearest  device.  The  chime  is  played  10  seconds  each 
time  and  lights  stay  on  till  location  changes.  Stop  if  pill  is  taken.  Escalate 
to  Plan  2  after  10  minutes. 

Plan  2  Prompt  using  all  prompting  devices  in  the  house  every  minute.  Lights 
on  devices  stay  on  and  chime  is  played  for  10  seconds  every  minute. 

Plan 1  =  prompt  Skip;  Wait (10 minute)',  Plan2  V  takenlyes  —>  Skip 

Plan2  =  prompt  Skip;  Wait(lminute);  Plan2  V  takenlyes  — ►  Skip 

Medi  =  (  [athome  A  -> taken  A  -i onThePhone  A  ~^sleeping]Plan\  -  rule  2-6 

□  leaving"! yes  — ►  Plan2)  -  rule  7 

V{dt  -  20minute}  Plan2  -  rule  8 

Where  calendar  _time(c,  Start)  ^  st  A 

calendar -time{c1  promp. Engage)  ^  st  +  dt  -  rule  1 

For  rule  6  :Prompting  will  resume  if  the  participant  returns  home  before  the 
window  expires. 

Our  modeling  is  able  to  reserve  this  requirement  in  a  more  clever  way.  Once  the 
participant  returns  home,  the  boolean  variable  athome  will  be  changed  to  true, 
hence  this  process  is  able  to  be  executed.  So  this  model  satisfies  a  more  general 
requirement: 

—  Prompting  will  resume  if  the  participant  returns  home  or  wakes  up  or  finishes 
phone  call  before  the  window  expires. 


8  Conclusion 


In  this  project,  we  formulated  a  more  complicated  scheduling  problem,  which 
we  call  Timed  Planning.  We  have  extended  the  Timed  CSP  with  capabilities 
for  stating  planning  related  requirements  in  a  compositional  way.  The  Timed 
Planning  has  more  expressive  power  than  Timed  Automata,  for  example  it  has 
the  capability  of  keeping  timed  event  set  during  execution  and  applying  some 
operations  on  the  set.  Due  to  the  expressiveness  of  CLP,  it  can  express  the 
syntax  and  semantics  of  Timed  Planning  fully.  A  mechanized  proving  system, 
based  on  CLP  (72.),  has  been  developed  to  check  the  schedulability  of  a  set  of 
tasks  and  various  safety  and  liveness  properties  can  also  be  verified  over  sys¬ 
tems  modeled  in  Timed  Planning.  We  studied  the  Japanese  Navy  plans  for  the 
Pearl  Harbor  Attack.  According  to  the  historical  documents,  we  modeled  the 
attack  plan  on  December  7,  1941.  We  also  applied  Timed  Planning  to  solve  the 
job-shop  scheduling  problems  which  can  be  naturally  modeled  as  Timed  Plan¬ 
ning  processes.  We  also  worked  with  the  extended  job-shop  scheduling  problems, 
where  all  jobs  have  composition  operational  behaviors.  Besides,  jobs  with  dead¬ 
line  and  relative  timing  constrains  are  also  able  to  be  captured  in  our  approach. 
We  believe  that  the  insight  gained  from  this  point  of  view  will  contribute  both 
to  scheduling  and  to  the  study  of  timed  planning.  We  have  demonstrated  that 
the  performance  of  the  timed  planning  approach  of  solving  job-shop  scheduling 
problem  can  be  highly  improved  by  applying  a  set  of  optimizations.  There  are 
still  many  potential  improvements  to  be  explored  to  reduce  the  execution  time, 
such  as  new  partial-order  methods  and  heuristics,  etc. 
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Appendix  A:  Operational  Semantics  of  Timed  Planning 

Stop 

(Stop,  t,  W,  Tss)  A  (Stop,  t  +  d,W,  Tss) 

Event  Prefix:  a  — >  Q 

Tss  U  {(a. Engager  t)}  |=  W 

- [  Tes  l  a  =  i  —  1  ] 

(a  — >  Q,  t,  W,  Tss)  A  (Q,  t,  W,  Tss  U  {(a. Engage;,  t)}) 


Skip 


a  — »  Q,t,  W,  Tss)  A  ( Q ,  t  +  d,  W,  Tss) 

Tss  U  {(/.Engage,  f)}  |=  W 

(Skip,  t,  W,  Tss)  ^  (Stop,  t,  W ,  Tss  U  {(End,  t)}) 

(Skip,  t,  W,  Tss)  4  (Skip,  t+d,W,  Tss) 

Timeout:  Q i  >{d}  Q 2 

Tss  U  {(a. Engage^  t)}  \=  W  Qi  A  Q[ 

- [  Tes  i  a  ==  i  —  1  ] 

(Qi  >{rf}  Qi,  t,  W,  Tss)  A  (Qi,  t,  W ,  Tss  U  {(a.ENGAGEi,  t)j) 

Qi  A 

(Qi  >{d}  Qi,  t,  W,  Tss)  A  (Qi  i>{d}  Qz,  t,  W,  Tss) 

(Qi  >{0}  Q2,  t,  W,  Tss)  A  (Qj,  t,  W,  Tss) 

Qi  •£  Qi 

(Qi  >{0}  Q2,  t,  W,  Tss)  £>  (Q[  t>{d  -  d'}  Q2,  t  +  d',  IE,  Tss) 

External  Choice:  Qi  □  Q2 

Tss  U  {a.ENGAGEi,  £}  |=  W  Qi  A  Q{ 

- [  Tes  |  a  =  i  -  1  ] 

(Qi  □  Qi,  t,  W,  Tss)  A  (Q{  □  Q2,  t,  W,  Tss  U  {(a.ENGAGEi,  f)}) 

Tss  U  {a.ENGAGEi,  £}  |=  W  Qi  A  Qi 

- [  Tes  {  a  =  i  -  1  ] 

(Qi  □  Q2,  t,  W,  Tss)  A  (Qi  □  Qi,  t,  W,  Tss  U  {(a.ENGAGEi,  t)}) 

Qi  A  Qi 

(Qi  □  Q2,  t,  W,  Tss)  A  (Q{  □  Q2,  t,  W,  Tss) 

Qi  A  Qi 

(Qi  □  Q2,  t,  W,  Tss)  A  (Qi  □  Qi,  t,  W,  Tss) 

Qi  ^  Q[  Q2^  Q2 

( Qi  D  Q21  ^  W »  Tss)  ^  (Q[  □  Q25 1  H-  d,  W,  Tss) 


Parallel:  Q1  x\\y  Q2 


Tss  U  {(e. Engage*,  t)}  \=  W  Qi  A  Qi 

(Qi  x  ||  y  Q2,t,  W ,  Tss)  A 

(Qi  x\\ y  Q2,t,  W,  Tss  U  {(e. Engage;,  t)}) 


[  e  £  X  U  {r}  \  Y,  Tes  l  e  =  i  -  1 


Tss  U  {(e. Engage;,  t)}  \=  W  Q2  Qi 

(Qi  x\\y  Q2,  t,  W,  Tss)  A 

(Qi  x\\ y  Qi,t,  W,  Tss  U  {(e. Engage;,  i)}) 


[  e  €  YU  {t}  \  X ,  Tes  {  e  =  i  —  1 


Tss  U  {(e.ENGAGE;,  t)}  \=  W  Qi  A  Qi  Q2  ^  Qi 

- [  e  E  X  n  Y,  Tes  | 

(Qi  x  ||  y  Q2Q,  W,  Tss)  —> 

(Qi  a  ||  y  Qi,t,  W,  Tss  U  {(e.ENGAGE;,  t)}) 


Tss  U  {(/.Engage,  t)}  | =  W  Qi^  Qi  Q2  £*  Qi 
(Qi  x  ||  y  Q2,  t,  W,  Tss)  £>  (Q{  a  ||  y  Qi,  t,  W,  Tss  U  {(End,  i)}) 

Qi  £  Qi  Q2£  Qi 

(Qi  Ally  Q2,t,  W,  Tss)  £  (Qi  x\\y  Qi,t+d ,  W,  Tss) 

Interleaving:  Qi  |||  Q2 

Tss  U  {(e.ENGAGE;,  1)}  \=  W  Qi  A  Qi 

- - - [  Tes  l  e  =  i  —  1  ] 

(Qi  HI  Q2,  t,  W,  Tss)  — > 

(Qi  III  Q-2 ,  t,  W,  Tss  U  {(e.ENGAGE;,  t)}} 


Tss  U  {(e.ENGAGE;,  t)}  \=  W  Q2  Qi 

- - - [  Tes  l  e  ==:  i  —  1  ] 

(Qi  III  Q2,  t,  W,  Tss)  A 

(Qi  HI  Qi,t,  W,  Tss  U  {(e.ENGAGE;,  t)}> 


Tss  U  {(/.Engage,  t)}  \=  W  Qi  £*  Qi  Q2  £>  Qi 
(Qi  III  Q2,  t,  W,  Tss)  £>  (Q(  ID  Qi,  t ,  W,  Tss  U  {(End,  1)}} 


Qi  £  Qi  Q2£  Qi 

(Qi  1 1 1  Q2 ,  t,  IE,  Tss)  (Qi  |j|  Q2,  t  +  d,  W ,  Tss) 


Appendix  B:  Healthiness  Conditions  for  Timed  Planning 

Implicit  predicates  for  most  of  the  process  operators  are  defined  as  follows,  where  P 
denotes  process,  e  denotes  event,  X  and  Y  are  set  of  events. 

Event  Prefix:  an  — >  P 

V  a  — >  P  •  a". Engage  <  P. Start 

Sequence:  PI;  P2 

V PI;  P2  •  PI. End  <  P2. Start 

Choice:  P1DP2 

VP1  HI  P2  •  PI. Start  =  P2. Start  a  PI. End  =  P2.End 
Timeout:  PI  >  {d}  P2 

VP1  >  {d}  P2  •  init{P  1}. Engage  <=  d  V  P2. Start  =  d 

Interleaving:  PI  |||  P 2 

VPi  HI  P2  •  Pi. Start  =  P2. Start  A  Pi. End  =  P2.End 
Interrupt:  PI  V  P2 

VPi  V  P2  .  Pi. Start  ^  P2. Start 
Timed  Interrupt:  PI  V  dP2 

VPi  V{d}  P2  •  Pi. Start  +  d  ^  P2. Start 
Parallel:  PI  x\\y  P2 

VPi  x\\y  P2, V a  €  X  fi  Y  •  Pi. Start  =  P2. Start  A 

Pi.  End  =  P2.End  a  Pi.  a.  Eng  age  =  P2.  a.  Engage 


